home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000138_misckit-reques…aska.et.byu.edu_Thu Feb 17 10:34:16 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  3KB
  1. Return-Path: <misckit-request@alaska.et.byu.edu>
  2. Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
  3.     id AA00828; Thu, 17 Feb 94 10:33:22 -0700
  4. Received: from darth.byu.edu by alaska.et.byu.edu; Thu, 17 Feb 1994 10:32:47 -0700
  5. Received: by darth.byu.edu (NX5.67d/NX3.0M)
  6.     id AA00821; Thu, 17 Feb 94 10:31:28 -0700
  7. Date: Thu, 17 Feb 94 10:31:28 -0700
  8. From: Don Yacktman <don@darth.byu.edu>
  9. Message-Id: <9402171731.AA00821@darth.byu.edu>
  10. Received: by NeXT.Mailer (1.100)
  11. Received: by NeXT Mailer (1.100)
  12. To: misckit@alaska.et.byu.edu
  13. Subject: Re: Breaking MiscKit into separate "levels"
  14. Reply-To: don@darth.byu.edu
  15.  
  16.  
  17. > Why is it necessary to have Object as a level?
  18.  
  19. Well, here's my line of reasoning, but I don't know enough
  20. about Obj-C on non-NeXT platforms, so I could be a bit off the
  21. mark here.
  22.  
  23. The idea was that List and HashTable are "NeXT" objects,
  24. and when you link an ObjC program, they are available to
  25. you under NEXTSTEP.  But what about other platforms?
  26. Are these classes always available, like object, when you
  27. link ObjC?  If so, then that level 1 and 2 should be the same.
  28. If not, then it seems they should be different; level 1 should
  29. be OK to use in any ObjC, but level 2 would require the user
  30. to add in HashTable and List.  Now, I know that there are free
  31. NeXT-compatible HashTable and List classes out there, but
  32. I thought you had to add them in by hand.  Wehn I saw them,
  33. they were a separate product, and not with the Object class.
  34. If that has changed...
  35.  
  36. So that's what I was thinking.  Level 1/2 were both still supposed
  37. to work on other ObjC platforms, though so it's no big deal if they
  38. were the same.  In that case, in fact, I'd say that the fewer
  39. divisions we have the metter, since that makes things easier
  40. to work with for the user, by far.  (In other words, I saw an artificial
  41. division out there, in the non-NeXT world...but that doesn't mean
  42. it is necessarily still there or worth paying attention to, really.)
  43.  
  44. I guess maybe that suggestion wasn't so bright...because even if
  45. List and HashTable aren't automatically included (are they?) you
  46. could make them a requirement for MiscKit users.  In fact, perhaps
  47. even have the MiscKit include them in level 1 automatically on
  48. non-NeXT platforms...
  49.  
  50. After Michael's description of the palette library, I can easily see
  51. where that would be a good thing.  Too bad it isn't working just
  52. yet.  The idea is really nice.  With all the palettes in the MiscKit,
  53. such a beast would be a really useful aid to MiscKit programmers.
  54. (However, it seems almost to be more of a sideways step from the
  55. other libraries rather than a direct descendant...)  Well, it is
  56. something else to think about adding to the kit someday... :-)
  57.  
  58. calling the libraries libMisc.a, libMiscKit.a, and libMiscAppKit.a
  59. sounds like a good approach, and is as good as anythings else
  60. I might come up with.  And Michael's header structure sounds
  61. like a good way to go.
  62.  
  63. Oh, and on Object...
  64. > >A common object protocol is necessary. (Mr Pugh?)
  65. > This must be resolved, but not my a lowly mortal like myself.
  66.  
  67. There wouldn't have been a problem if NeXT went with what
  68. Brad Cox already had.  what were their reasons for deviation?
  69. Were there really good reasons, or was it just for ego?
  70.  
  71. ---
  72. Later,
  73.  
  74. -Don Yacktman
  75. Don_Yacktman@byu.edu